I am a bit unclear about the reason for this construction. Is it to be able to do attribute(section("SSRAM1")) after having configured the device tree, then that is very handy. But doesn't really require specific ADDRESS.

Or are there use cases I am not thinking about here?

The reason for this is when devicetree defines memory regions, for example like DTCM in this case:

then the linker generator should create a corresponding memory region and section.
For example for ld scripts like this:

MEMORY                                                                                              
{                                                                                                   
  ...
  DTCM (rw) : ORIGIN = (0x30000000), LENGTH = (0x80000)                                             
  ...
}

DTCM 0x30000000 (NOLOAD) :                                                                          
{                                                                                                   
  __DTCM_start = .;                                                                                 
  *(DTCM)                                                                                           
  *("DTCM.*")                                                                                       
  __DTCM_end = .;                                                                                   
} > DTCM                                                                   

and there the address of 0x30000000 should of course correspond to the address defined in devicetree.

By using the memory region node from devicetree we remove the requirement that the user must duplicate this information in CMake.

In CMAKE_LINKER_GENERATOR linker scripts, avoid placing the device tree memories at an absolute address. This avoids placing both .rom_start AND SSRAM1 at the same address on mps2/an521/cpu0.

I see how this could be a problem to some linkers, and is probably not noticed until now because as you mention then ld has no problems with such colliding addresses.

I looked a bit at the ld generator, and it seems the ld generator is actually using the value from the memory region (zephyr_linker_dts_memory()) and not the value given fetched in zephyr_linker_dts_section(), which means that the change in this PR doesn't seem to affect the ld generator.
I need to check the scatter file generator before a potential approval.

By using the memory region node from devicetree we remove the requirement that the user must duplicate this information in CMake.

This was something like I expected. But I still don't see anyone using the actual sections.. And this usage is not easy to search for.
To follow your example above, dtcm sections are still specified in arm/linker.cmake and it doesn't seem like anyone is placing stuff in sections with the automatically generated name DTCM/ITCM/SSRAM1 etc.

To follow your example above, dtcm sections are still specified in arm/linker.cmake and it doesn't seem like anyone is placing stuff in sections with the automatically generated name DTCM/ITCM/SSRAM1 etc.

That could be because not all code placement has been updated.
For example, DTCM region was originally added here: #17123

And the creation of memory regions and sections based on devicetree was added here: #43603
See also #42008 for additional info.

The ld-templates still creates the same memory regions and sections as we should be doing in the CMake linker:

@carlocaione do you have any additional input regarding this topic ?

yup, matching the ld skeletons is the best way.
This is an interesting discussion but have we actually uncovered anything stopping this change?

@nhutnguyenkc

Looks good. We will try IAR on Renesas boards soon.

Ah good!

We have a known issue that CMAKE_LINKER_GENERATOR is not in sync with LD skeleton for renesas boards (option bytes).
I have been meaning to look into it but maybe you can do it?

e.g. for ek_ra4e2

Error[Lc036]: no block or place matches the pattern "ro data section .id_code in bsp_rom_registers.c.o"
Error[Lc036]: no block or place matches the pattern "ro data section .option_setting_bps_sec0 in bsp_rom_registers.c.o"
Error[Lc036]: no block or place matches the pattern "ro data section .option_setting_ofs0 in bsp_rom_registers.c.o"
Error[Lc036]: no block or place matches the pattern "ro data section .option_setting_ofs1_sec in bsp_rom_registers.c.o"
Error[Lc036]: no block or place matches the pattern "ro data section .option_setting_pbps_sec0 in bsp_rom_registers.c.o"
Error[Lc036]: no block or place matches the pattern "ro data section .option_setting_sas in bsp_rom_registers.c.o"

@RobinKastberg , it seems now is the right time to try IAR :)
Could you please share us the build command to reproduce these errors?
I think @thenguyenyf can help you with that. We can find each other on Discord for further discussion.